Hi — the fix from this PR is confirmed working in ghcr.io/ansible/ansible-devspaces:v26.4.5 (the old UID 10001 user is gone). However, we're still seeing duplicate /etc/passwd entries at runtime in OpenShift DevSpaces:

user:x:1000:1000::/home/user:/bin/bash
user:x:1000860000:0:user user:/home/user:/bin/bash

The second entry is injected by OpenShift's CRI-O runtime when the SCC assigns a UID from the namespace range. Since the image already has user at UID 1000, this creates a name collision — two user entries with different UIDs.

This causes:

• getent passwd user resolving to UID 1000, while the process actually runs as 1000860000
• Potential issues with terminal spawning and environment resolution in che-code

Tracking the runtime behavior issue separately at rhpds/ansible-dev-tools-workspace#10. This may need a different approach for the DevSpaces image (e.g., not pre-creating user in the image, or using a different username to avoid the collision).

Follow-up on the sudo fix — we tested on DevSpaces 3.27.0 / OCP 4.21.9 and sudo still doesn't work on either v26.4.4 or v26.4.5.

v26.4.4 (tenant user-bm7f6):

$ id
uid=1000940000(user) gid=0(root) groups=0(root),1000940000
$ groups
root 1000940000
$ sudo whoami
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

v26.4.5 (tenant user-jtvxh):

$ id
uid=1000900000(user) gid=0(root) groups=0(root),1000900000
$ groups
root 1000900000
$ sudo whoami
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

The workspace pods land on the restricted-v2 SCC, which sets allowPrivilegeEscalation: false and drops all capabilities. This may prevent setuid binaries from working regardless of the UID/passwd fix.

The UID cleanup from this PR is likely still a prerequisite for sudo to work, but it may not be sufficient on its own — the SCC/security context also needs to allow privilege escalation. Still investigating whether this is a cluster configuration issue or something that needs to be addressed in the DevWorkspace/CheCluster setup.

We need to figure out if there are specific SCC settings, CheCluster configuration, or DevWorkspace attributes required for sudo to work in DevSpaces — this will need to be addressed in the documentation for GA as part of the configuration requirements.

Tracking at rhpds/ansible-dev-tools-workspace#10.

cc @cgruver @alisonlhart @cidrblock

@leogallego I successfully started a workspace from this repo, main revision.

Sudo works as expected. When you are online today, ping me and we'll take a look at your config.